Electronic health record system utilizing disparate record sources

ABSTRACT

A system for facilitating patient ownership of his or her medical data through the use of third-party health repositories that preserves the maximum information content of the medical records by displaying information relevant to the authority of the medical data as reflected by its source and types of modification as it has moved between institutions, as well as the data itself. In this way, improved use of this data is made possible.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.12/391,120, filed Feb. 23, 2009 now U.S. Pat. No. 8,249,895, which inturn claims the benefit of U.S. provisional application 61/030,734 filedFeb. 22, 2008 both of which are hereby incorporated by reference.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

--

BACKGROUND OF THE INVENTION

The present invention relates to electronic medical records and, inparticular, to an electronic medical record system providing improvedintegration of portable medical records.

Electronic medical records offer a number of advantages overconventional paper-based recordkeeping. First, the cost of generating,storing, and accessing electronic medical records is potentially muchlower than for comparable paper- or document-based record systems.Electronic medical records are more resistant to loss or damage and,with the increased availability of computer devices with display andnetworking capability, the speed and convenience of accessing electronicmedical records is far superior to their paper counterparts. Electronicmedical records facilitate the collection of all relevant informationfor a particular patient in a single system, giving healthcare providersa more complete view of the patient's health. Because electronic medicalrecords are machine-readable, they may be analyzed with programs toassess the efficacy of particular courses of treatment, to provideautomatic notices or devise theories, and to otherwise automate theprocess of delivering high-quality health care services.

Electronic medical records also promise to improve the patient's accessto his or her own records and thus beneficially increase patientinvolvement in the healthcare process. Healthcare providers havingelectronic medical record systems may provide Web portals to theirpatients allowing protected access by the patient to selected healthcareinformation. One such system is the MyChart™ healthcare portalcommercially available from Epic Systems Corporation of Verona, Wis.Such healthcare portal systems should be distinguished from healthcarewebsites which allow the patient to record healthcare information but donot provide patient access to clinical medical records collected byhealthcare professionals.

A third benefit to electronic medical records is that they are easilytransported, for example on optical or digital media or over theInternet, and in this way can provide continuity in a patient's medicalhistory as the patient moves among institutions. Toward this end, anumber of organizations both within and outside of the healthcareindustry (such as Google and Microsoft) have taken steps toward creatinghealth data repositories that might serve to hold electronic medicalrecords in the standard formats under the control of a patient. Thesedata repositories foresee the possibility that patients will become thecustodians of their own medical records in alignment with U.S. lawgiving patients ownership of their medical record data.

SUMMARY OF THE INVENTION

The present inventors have recognized that the benefits of a patientcontrolling his or her medical records can be at odds with the patient'sdesire that the physician have authoritative medical data on which thephysician may rely. While a patient's characterizations of his or hermedical condition is an important element in obtaining a completepicture of the patient's health, patient-edited data or data that iscorrupted or materially redacted can be confusing or misleading, a factthat may lead physicians to give this data very little weight.

The promise of health record portability from third-party recordrepositories may fall far short of expectations if patient-stored and-transported health records are ignored by physicians or treated as nobetter than a patient health history questionnaire currently filled outby patients when moving to a new physician or medical practice.

The present invention addresses this problem by generating andpreserving additional data related to the authority of transferredmedical records. This authority information may be displayed to thephysician concurrently with the display of the underlying medical dataallowing the physician to better assess and thus more fully use datathat has been transferred from other sources. In this respect, thepresent invention may distinguish among physician-generated data havingthe highest authority, patient-collected data (entrusted to the patientby another institution) having various levels of authority depending onthe degree of editing and redaction of the data and patient-generateddata having lesser authority for some types of data. In differentembodiments, the value of the data is further enhanced by displaying thesource of the data (e.g. a particular hospital or institution collectingthe data) and the extent to which the data may omit important elements.

In this context, “physician-generated” data will mean clinical medicaldata generated by the physician or other health care professionalworking with the physician, “patient-collected” data will mean clinicalmedical data entrusted to the patient and being transferred under theauthority or control of the patient, while “patient-generated” data willmean medical information developed by the patient using the patient'sown observations or memory. “Patient-generated” and “patient-collected”data will sometimes be referred to collectively as “patient-controlled”medical data.

Specifically then, the present invention provides a health record systemintegrating a first and second clinical record system associated withdifferent medical institutions and the medical record repository. Thefirst clinical record system, associated with the first medicalinstitution, provides at least one computer communicating with a set ofdata terminals and a first database executing a first stored program tocollect, organize, and display physician-generated medical data forgiven patients. The first clinical record system includes anauthentication protocol limiting access by non-healthcare professionals.The medical record repository likewise provides at least one computercommunicating with a set of data terminals and a repository database andexecuting a repository stored program to collect, organize, and displaymedical data controlled by given patients. The medical record repositoryincludes an authentication protocol limiting access by others than thegiven patients.

In the invention, the repository program of the medical recordrepository operates to:

(a) accept into the repository database patient-generated medical datafrom a given patient;

(b) accept into the repository database patient-collected medical datafrom a second clinical record system of a second medical institution ina manner to be separately identified from the patient-generated data;and

(c) respond to authorization by the given patient to transmit at leastsome of the patient-generated data and patient-collected data to thefirst clinical record system.

Using information from the medical record repository, the first storedprogram of the first clinical record system further operates to providea display output providing medical data for the given patient visuallylinked to an indication of an authority of the data based on itsidentification as physician-generated, patient-generated, orpatient-collected.

It is thus a feature of at least one embodiment of the invention toprovide not only medical data but also to indicate the authority of thedata improving the ability of the physician to use data from othersources.

The repository program further stores an identification of the secondmedical institution which may be displayed by the first program.

It is thus a feature of at least one embodiment of the invention toprovide the physician with the ability to both judge medical data basedon its specific source and to permit rehabilitation of data that mayhave lost its authority, the rehabilitation being done by the physiciancontacting the original source.

The medical data may have a data type related to a medical character ofthe data and independent of a source of the data and the first storedprogram may further operate to display physician-generated,patient-generated and patient-collected data sorted according to datatypes, so that similar data types are proximate to each other in thedisplay.

It is thus a feature of at least one embodiment of the invention toallow visual integration of data from multiple sources in the display bydata type, making the data more accessible to a physician, withoutobscuring the underlying authority of the data.

The repository program may accept health record documents from thesecond health institution comprised of multiple elements of medical dataand may allow the given patient to selectively authorize a subset of themedical data of the document for transmission to the first clinicalrecord system. The repository program may separately identify medicaldata associated with a document in which some medical data was notauthorized for transmission to the first clinical record system frommedical data associated with a document in which all medical data wasauthorized for transmission to the first clinical record system.

It is thus a feature of at least one embodiment of the invention toprovide an indication to the physician that there may have been materialomissions in a transferred medical record, lowering its authority, eventhough the included portions of the medical record are of highauthority.

The repository program may allow editing of the patient-collectedmedical data by the given patient and the repository program mayidentify such edited medical data in a manner to be separatelyidentified from medical data unedited by the given patient.

It is thus a feature of at least one embodiment of the invention toindicate that clinical medical data may have been edited or changed bythe patient, thus implicitly lowering its authority.

Patient-collected data edited by the given patient may be identified aspatient-generated data by the repository program.

It is thus a feature of at least one embodiment of the invention toprovide a simple method of categorizing the authority of edited clinicaldata.

The repository program may accept health record documents of medicaldata from the second health institution and evaluate a digital signatureor watermark in the documents, or the quality of a secure channel usedto transfer the document, or other technological authentication systemto ensure the documents have not been edited after release by the secondhealth institution before identifying them as patient-collected data. Asused herein, document shall refer to a collection of medical datareceived from a clinical institution presenting a cohesive view of thepatient's health information and subject to a common authenticationmechanism.

It is thus a feature of at least one embodiment of the invention topermit the use of clinical data transferred under the custody of thepatient without necessarily degrading its authority. The watermarkingprocess allows control of the files to be transferred while ensuringtheir integrity.

Alternatively, the repository program may communicate electronicallydirectly with the second health institution to obtain patient-collecteddata.

It is thus an object of the invention to provide a system of transfer ofclinical data without loss of authority using a trusted third-partyintermediary.

The repository program may further communicate with the first program toprovide a display output of the physician-generated data for the givenpatient to the patient using the repository program.

It is thus a feature of at least one embodiment of the invention toprovide a mechanism allowing the patients to view their clinical recordsin combination with the management of clinical records from multiplesources.

The second program may further operate to:

accept into the repository database patient-collected medical data fromthe first clinical record system in a manner to be separately identifiedfrom the patient-generated data; and

respond to authorization by the given patient to transmit at least someof the patient-generated data and patient-collected data to the secondclinical record system.

It is thus a feature of at least one embodiment of the invention toprovide a conduit for medical data between multiple institutionscurrently providing patient care.

The repository program may further operate to respond to authorizationby the given patient to transmit at least some of the patient-generateddata to the second clinical record system.

It is thus an object of the invention to provide a simple mechanism fora patient to update records at multiple institutions

These particular features and advantages may apply to only someembodiments falling within the claims and thus do not define the scopeof the invention.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a graphical representation of the transfer of clinical medicaldata between a first and second clinical institution via a health datarepository serving to link the two;

FIG. 2 is a logical representation of a database of the health datarepository in collecting healthcare information for a given patient, thedatabase preserving data source, organization, sharing, and editinginformation;

FIG. 3 is a flow chart of a program executed by a clinical record systemat the first clinical institution for displaying medical data, includingmedical data from the health data repository and providing authorityindicia for that data; and

FIG. 4 is a simplified representation of a display of the data aspresented to a physician marked by authority levels and using anauthority threshold.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring now to FIG. 1, first and second clinical institutions 10 and12, such as hospitals or clinics or the like, may provide for electronicmedical records systems 14 and 16 respectively. As is generallyunderstood in the art, medical record systems 14 and 16 may store,organize, and display clinical medical data for patients. As usedherein, clinical medical data refers to medical information based ondirect observation of patients by healthcare professionals.

The electronic medical record systems 14 and 16 may employ one or moreelectronic computers 18 executing stored programs 20 to implement adatabase 22 holding the clinical medical records as well as the otherfeatures are of the electronic medical record system. Multiple terminals26 may communicate with the computer 18 through a local area network orvia the Internet to allow access to the medical records by healthcareprofessionals of the institutions 10 and 12. This access is controlledby an authorization protocol implemented by the programs 20 to limitaccess by non-healthcare professionals, for example, through the use ofa password/username combination or other well-known authenticationtechniques. This limitation of access may admit to multiple permissionlevels allowing some access, for example, selective read access by thepatients for their own records. Generally, the records within thedatabases 22 are subject to the recordkeeping requirements andregulations of the Health Insurance Portability and Accountability Act(HIPAA). These clinical records will be termed physician-generated,recognizing that they may be developed by a broad class of healthcareprofessionals including but not limited to physicians.

Electronic medical record systems 14 and 16 suitable for this purposeare commercially available from Epic Systems Corporation and aredescribed by multiple published U.S. pending applications assigned toEpic Systems Corporation including: 2008/0033761 “System and method fora seamless user interface for an integrated electronic health careinformation system”; 2007/0143149 “Data tagging and report customizationmethod and apparatus”; 2006/0080620 “Electronic system for collectingand automatically populating clinical order information in an acute caresetting”; 2003/0220815 “System and method of automatically determiningand displaying tasks to healthcare providers in a care-giving setting”;2003/0216945 “Method for analyzing orders and automatically reacting tothem with appropriate responses”; 2003/0208391 “Rules based ticketingfor self-scheduling of appointments”; 2003/0208381 “Patient healthrecord access system”; 2003/0139943 “Healthcare information system withclinical information exchange”; 2003/0130872 “Methods and apparatus formanaging and using inpatient healthcare information”; 2003/0061073“Method and system for displaying patient information”; 2002/0120472“System and method for integration of health care records”; 2002/0083075“System and method for a seamless user interface for an integratedelectronic health care information system”; and 2002/0080189 “Electronicsystem for collecting and communicating clinical order information in anacute care setting” all hereby incorporated by reference.

Referring still to FIG. 1, a given patient may record and accesspatient-generated medical information by means of a health datarepository 30, for example, accessible over the Internet by the patientusing a home data terminal 32.

In this regard, the health data repository 30 may use one or morecomputers 35 executing a stored program 33 to implement a database 34used to hold the patient-generated medical records as well as implementother features of the health data repository 30 to be described. Thehome data terminal 32 may, for example, use a browser program to connectwith a Web server implemented by the stored program 33 of the healthdata repository 30. Typically, the patient may use the home dataterminal 32 to enter patient-generated medical information includingeasily measured health data (height, weight etc.), allergies,medications, and information that may be duplicated by the records ofthe databases 22 as recalled by the patient.

A health data repository 30 differs from a personal health record (PHR)to the extent that it also allows importing of clinical medical datafrom the databases 22. For this purpose, the health data repository 30may provide for a direct network connection 38 via the internet or othermeans with the computers 18 of the institutions 10 and 12 which maytransfer medical records from the databases 22 using, for example, acommon document format such as the Continuity of Care Document (CCD)described by ANSI standard ANSI/HL7 R1-2000, R2-2005 hereby incorporatedby reference or the Continuity of Care Record (CCR) described by ASTMCCR standard E2369-05 hereby incorporated by reference.

The goal of the health data repository 30 is to provide for control by apatient of the patient's health record and thereby to assist inpreservation of medical records as a patient moves between institutions10 and 12 through his or her life providing continuity in these records.

Prototype health data repositories 30 of this type are currently beingoffered by Epic Systems Corporation under the Lucy trademark, byMicrosoft Corporation under the HealthVault tradename and by GoogleCorp. under the tradename Google Health.

The present invention contemplates that the program 33 of the healthdata repository 30 will give the patients considerable latitude inorganizing their medical information in the health data repository 30,both patient-generated and physician-generated. In such systems, thepatient-generated and physician-generated data will be collectivelyreferred to as patient-controlled data.

Specifically, such health data repositories 30 may provide one or moreof the following features: selective sharing or redaction of portions ofphysician-generated medical data documents, elimination of the duplicatepatient-controlled medical data, selection among conflictingpatient-controlled medical data, and editing (including creation) ofpatient-controlled medical data. The selective sharing feature allows apatient to provide an indication associated with elements of medicaldata indicating whether the patient wishes to have the elements sharedwith the institutions 10 and 12. Using this sharing feature, medicaldata control by the patient may be automatically forwarded to each ofthe institutions (or automatically transferred by institution request)providing a simple method of updating the multiple institutions 10 and12 both with patient-generated data and with physician-generated datafrom the other institution. Documents uploaded by the patient from aninstitution 10 or 12 may have all or portions of the documents shared sothat some portions of the documents are not shared. A functionallysimilar approach allows redaction of elements of the documents by thepatient in the database of the repository so that these records are alsoremoved from access by the patient as well as anyone else accessing therecords from the repository.

As data is imported from different institutions or provided by thepatient to the health data repository 30, duplications in the data mayoccur. If the duplicate data is the same, the program 33 of the healthdata repository 30 may allow the patient to delete redundant data withrespect to its display to the patient and/or sharing. Alternatively, ifthe duplicate data is different, the patient may reconcile the dataselecting one data element in favor of the others and deleting orredacting the others. In addition, the health data repository 30 throughprogram 33 may permit the patient to edit the data, changing its value.

Referring to FIG. 2, a database 34 of the health data repository 30 maybe logically represented tabularly as a set of records 40 eachrepresented by one row of a database 34 with each of the records 40divided into fields represented by columns of the table. It will beunderstood that this logical representation embraces a variety ofdifferent database organizational structures of types well known in theart, and further that it is a simplification and that an actual databasewill include different fields and organization.

As shown in FIG. 2, the first field 42 may provide a unique number foreach record 40 and a second field 44 may provide for a patientidentification, being a unique number or the like identifying a patientfrom others. The patient identification may provide a link to otherinformation about the patient including name, address, and the like. Inthis case, the records 40 of the single patient are shown whichrepresents a minimum health data repository 30. Typically, the healthdata repository 30 will serve multiple patients, and so the patientidentification may also link to a username/password for implementing asecure logon to health data repository 30 limiting access to thepatient's records 40 by persons other than the patient.

A next field 46 may provide a machine-readable data-type indicating thetype of medical data represented by the record 40. The data type offield 46 may be followed by the particular medical data of field 48. Forexample, the data type of field 46 may be allergy information and themedical data of field 48 may be the allergen.

The present invention contemplates one or more additional fields 50-58which increase the usability of the data as it is transferred. The firstfield 50 indicates whether the data was patient-generated (P) orpatient-collected (C). As noted above, “patient-collected” data willmean clinical medical data entrusted to the patient and beingtransferred under the authority or control of the patient, while“patient-generated” data will mean medical information developed by thepatient using the patient's own observations or memory.“Patient-collected” data can include data collected from automaticmonitoring equipment.

The next field 52 provides an attribution or source forpatient-collected data (for example, an identification of a particularhospital or clinic). These two fields can be conflated into one, with ablank entry in field 52, indicating patient-collected data, and allother data being considered patient-generated.

The present invention contemplates that this field can hold not only thename of the institution, but potentially, also the name of the healthcare professional responsible for the collection of the data eitherdirectly or under his or her supervision (“the sourcing physician”). Ineither case, a field 51 is provided allowing the health careprofessional responsible for the data to highlight or flag certainrecords 40 with respect to their importance. This highlighting (shown asan * in FIG. 2) does not change the medical data but like the otherinformation in fields 50-58 serves to characterize the significance orauthority of the data. A numeric ranking scale of importance may also beemployed.

The next fields 53 and 54 apply to patient-collected data and providethe document structure of the data, field 53 providing a unique documentnumber that will be shared by all data (records) associated with asingle document (e.g. CCD, CCR). Field 54 provides unique numbers ofeach record 40 of that document. The numbers of these fields may bechosen arbitrarily so long as they are unique for each document and foreach record 40 within a document.

Field 56 provides a set of sharing codes indicating the patient'spreference for sharing of the particular record 40. A given record 40 ordata element may be shared (Y) or not shared (N) on a record 40 orelement-by-element basis. These sharing codes may be expanded to permitsharing to particular institutions 10 or 12 and not to others.

The field 58 provides an edit code allowing the program 33 todistinguish among a variety of types of modifications of the records 40or their environment. The edit codes may include, for example: notedited (N), duplicate (D), redacted (RD), reconciled (R), and edited(F). No editing is self-evident and indicates that the medical data ofthe record 40 controlled by the patient has not been edited by thepatient, his may be established, for example, by watermarking techniquesfor example using public-key encryption) associated with the record 40or through a direct downloading of the record 40 to the health datarepository 30 under the control of the health data repository 30.Patient-generated data can never be classified as not edited (N) but isalways automatically classified as edited (E). Patient-generated data,however, may be attributed to a clinic or the like by the patient usingfield 54 (such attribution is not shown in FIG. 2).

The edit code of duplicate (D) is used when a record 40 received from aninstitution 10 or 12 provides duplicate information (identical data typeof field 46 and data value of field 48) that is already in the database34 from another institution 10 or 12 or from the patient. The existenceof duplicate records 40 may be noted to the patient during a mergingprocess when that document is received and need not alter or erase dataof the record 40 but only indicates that the record 40 is a duplicateand ideally provides pointers to the other records 40 with whichduplication exists. This edit code may be used, for example, by thehealth data repository 30 to prevent the display of redundant data.

In the example of FIG. 2, records 2 and 7 both indicate a penicillinallergy recorded by different institutions 10 and 12 and each may bemarked as a duplicate.

The edit code of redacted (RD) may be used to indicate that a portion ofa document is missing (deleted or not shared) per records 3 and 4. Notethat the edit code of (RD) is attached to non-redacted data, andindicates that other data of the document was redacted. In analternative embodiment of the invention, multiple edit codes arepossible for each record 40, so, for example, records 5 may have the(RD) edit code and the (R) edit code. Or the edit codes may conflate toone edit code as shown.

The edit code of reconciled (R), unlike duplicate, indicates that thepatient made a selection among inconsistent records 40 for duplicatedata types. For example, record 5 and record 8 may indicate differentclinical data values for medical data related to a medical type, forexample weight, and the patient may select between these. Again, eachreconciled record 40 may preserve a link to the other records 40 withwhich it was reconciled so that the complete data set can bereconstructed.

Referring now to FIG. 3, the database 34 of FIG. 2 allows asophisticated integration of this data into the clinical medical recordsof databases 22 by a program 20′ being, for example, part of program 20.Using program 20′, institution 12, for example, may receive data from ahealth data repository 30. This receipt of data may be incident withreceiving a new patient for care (the patient having a health datarepository 30). Alternatively, the receipt of data may occur as part ofan ongoing relationship with a patient who uses multiple institutions 10and 12, the data being transmitted from the health data repository 30 ona regular basis or by request by the patient or the institution 10 or12. While the data from the health data repository 30 has great value,as noted above, not all of the data has the same authority. Accordinglyupon receipt of the data, program 20′ undertakes an assessment of thedata using all or some of the information from the editing fields 50-58preserved by the health data repository 30.

This evaluation may be performed per any of the events described aboveas indicated by decision block 64. For each record 40, as indicated byprocess block 62, the record 40 may be evaluated to determine whetherthere is an attribution (field 52) as indicated by decision block 64 orwhether the record 40 is patient-generated as recorded by field 50. Ifthere is no attribution or the data is patient-generated, then therecord of 40 is marked as patient-generated per process block 66.

If there is an attribution and the record 40 is part of apatient-collected document having other records 40, then at decisionblock 67 it is determined whether the entire document (that is all ofits records 40) is marked for sharing per field 56. If any of therecords 40 are not marked for sharing, then at process block 68 all ofthe records 40 of that document are marked as redacted, indicating thatthe data is accurate but some, possibly material, medical data may beomitted.

In either case, at succeeding decision block 70, the record 40 isevaluated to determine whether it has been edited. Regardless of itsprevious attribution, if the document was edited, then at process block72, the record 40 is marked as edited; however, the attribution that isthe source of the document may still be retained. Generally, in the caseof patient editing, any marking of the record as important by thesourcing physician is removed.

If the document has not been edited, then the program 20′ proceeds todecision block 74 to determine if the particular record 40 has beenmarked duplicated by the health data repository 30. If so, at processblock 76, the record 40 is marked a duplicate and the attribution of theduplicate record 40 is retained providing information to the physicianthat multiple institutions have validated this particular piece of data.Any marking of either redundant record as “important” by the sourcingphysician is preserved and attached to the displayed record.

If the record 40 was not marked as a duplicate, it is examined atdecision block 78 to see if it has reconciled data and, if so, atprocess block 80 the data is marked as reconciled. Optionally, theattributions for the reconciled data may be saved as well as the valuesof that data. If one of the reconciled records has been marked as“important” by the sourcing physician, this importance may be displayed,provided the unreconciled records is also displayed as will be describedbelow.

This process is repeated per process block 82 in a loop until records 40from the health data repository 30 are analyzed and marked. The markeddata may then be integrated into the database 22 after which the program20′ may proceed to process block 84 to display, the records to thephysician.

During the display process 84, the marked records from the health datarepository 30 may also be in conflict or duplicated with existingclinical records of database 22 at the institution 12. The program 20′may automatically delete or hide duplicate records received from thehealth data repository 30 in favor of the high authority records of theclinical database 22 and likewise may reconcile any conflicting data tothe high authority records of the clinical database 22, optionally withconfirmation and possible override by the physician.

The display process 84 may permit selecting among the types of markingsthat will be displayed. For example, the “redacted” marks may besuppressed if the physician is not interested in this level of detail.

Referring now to FIG. 4, a typical display for such a system woulddisplay the patient name as deduced from the patient ID of field 44together with selected medical data 90 culled from the records 40 of thepatient, for example, selected from the database 22 through a databasequery executed by the physician or automatically being part of apredefined form. Different display modes 92 (for example highlighting orcolor) may optionally be applied to the data 90 to indicatequalitatively the authority of the data. Preferably, the highest qualitymedical data may be highlighted according to a threshold that may beprogrammed by the institution 12 separating among the various levels ofauthority ranked generally as follows:

Level of Authority Source Medical Data 1* Data with attribution, notedited or redacted, but duplicated by multiple institutions, flagged bysourcing physician as important 1 Data with attribution, not edited orredacted, but duplicated by multiple institutions 2 Data withattribution, not edited or redacted and not duplicated 3 Data withattribution, not edited, but reconciled 4 Data with attribution, notedited but some data redacted 5 Data with attribution, edited 6Patient-generated, edited data

For example, data with authority values 1-3 may be highlighted ashigh-quality data for the physician. Alternatively, the display ofrecords may be controlled by their authority level with a physicianselecting by filter settings, a desired level of authority of alldisplayed records. In this case, for example, the physician may set theauthority level to level 3 or below (levels 1-3) in which case dataassociated with levels 4-6 would not be displayed. Similarly, individuallevels may be suppressed, for example, level 5, while allowing level 6.

Each element of medical data derived from a record may be furtherlabeled with a label providing additional physician guidance. Forexample, authority level 5 data (shown in FIG. 4 as “medical data 1”)may be marked with the text “patient-generated” or a similarabbreviation or symbol. Similarly as shown with “medical data 3”, datawith an attribution (e.g. institution 10 or 12) but edited will beindicated as patient-generated yet the attribution retained. This allowsthe physician to confirm the data with the institution if desired andpreserves the attribution information even though it may not provideself-authentication.

As indicated with “medical data 4”, un-edited data from an institutionwhere the data is part of a document having some data removed orunshared, may be labeled “redacted” and the institution attributionprovided. Data from the clinical database 22 of institution 12 itself,for example, “medical data 2” may be highlighted with no attributionindicating that it is internal data of the highest quality.

High quality data from another institution being part of a document thathas neither been edited nor redacted, as indicated by “medical data 5”and “medical data 7” and the data that has been reconciled with otherhigh-authority data from other institutions that has neither been editednor redacted, shown by “medical data 8”, may be displayed as high-valuewith the rejected values and their attributions displayed. As shown by“medical data 5” any data marked as important by a physician in thesourcing institution may be marked as such.

Duplicate data may select the data of the highest authority to display.Reconciled data may further show the attributions together with theconflicting data.

The present invention thus provides a method for a physician to obtainthe very best data that has been collected for his or her patient while,also understanding the chain of custody of that data to the extent thatit can affect the data's authority and the physician's decisions. Notethat the authority provided by the present invention necessarily variesin importance depending on the type of data and the amount ofreconciliation. For example, inconsistent data related to the patient'sweight may be easily understood (within certain ranges) as being ofrelatively low significance. Further, some types of clinical informationthat are patient-generated or sourced from a redacted or edited documentmay nevertheless be perfectly acceptable because there is littlelikelihood of a serious mistake or missing data being materiallyrelevant to the data provided. Other data may be more sensitive to anyediting or redaction and the redaction itself may be significant to thephysician in certain cases even when the data itself has not beenshared.

It will be understood that the term physician as used herein includesany authorized health care professional using the clinical recordssystem.

It is specifically intended that the present invention not be limited tothe embodiments and illustrations contained herein and the inventionshould be understood to include modified forms of those embodimentsincluding portions of the embodiments and combinations of elements ofdifferent embodiments as come within the scope of the following claims.

We claim:
 1. A computer-implemented method for use in a medical recordrepository, the computer-implemented method comprising: (a) storingpatient-generated medical data from a patient in a medical recordrepository database on a first computer system; (b) storingpatient-collected medical data relating to the patient from a clinicalrecord system in the medical record repository database; (c) storingphysician-generated medical data relating to the patient from at leastone clinical record system in the medical record repository database;(d) storing an indicator in the medical record repository databaseidentifying stored medical data as patient-generated, patient-collectedor physician-generated, wherein physician-generated medical data isidentified as medical data that has not been collected or generated by apatient; (e) displaying, via a processor, at least one of thepatient-generated, patient-collected, and physician-generated medicaldata for the patient; wherein the at least one of the patient-generated,patient-collected, and physician-generated medical data is visuallylinked to a visual indication of an authority of the data based on itsidentification as physician-generated having a high level of authority,patient-collected having a medium level of authority, andpatient-generated having a low level of authority; (f) displaying anumerical ranking indicating the level of authority associated with themedical data.
 2. The method of claim 1, further including storing anidentification of a medical institution associated with each clinicalrecord system.
 3. The method of claim 2, wherein the visual indicationof authority identifies a medical institution.
 4. The method of claim 1,further including storing an indication of the importance of at leastone physician-generated medical data as assigned by a health careprofessional.
 5. The method of claim 4, further including displayingmedical data for the given patient visually linked to a visualindication of an importance of the data assigned by the health careprofessional.
 6. The method of claim 1, wherein the medical data has adata type related to a medical character of the data and independent ofa source of the data and displaying the numerical ranking includesdisplaying physician-generated, patient-generated and patient-collecteddata sorted according to data types, so that similar data types areproximate to each other in the display.
 7. The method of claim 1,further including receiving authority filter parameters from thephysician to suppress the display of medical data based on itsidentification as physician-generated, patient-generated, orpatient-collected.
 8. The method of claim 1, further including receivingauthority filter parameters from the physician to suppress the displayof selected visual indications of authority.
 9. The method of claim 1,further including accepting health record documents comprised ofmultiple medical data from a second health institution and allowing thegiven patient to selectively authorize a subset of the medical data ofthe document for transmission to the first clinical record system,including separately identifying medical data associated with a documentin which some medical data was not authorized for transmission to thefirst clinical record system from medical data associated with adocument in which all medical data was authorized for transmission tothe first clinical record system.
 10. The method of claim 1, wherein therepository program allows editing of the patient-collected medical databy the given patient and wherein the repository program identifies suchedited medical data in a manner to be separately identified from medicaldata unedited by the given patient.
 11. The method of claim 10, whereinpatient-collected data edited by the given patient is identified aspatient-generated data by the repository program.
 12. The method ofclaim 1, further including accepting health record documents of medicaldata from a second health institution and evaluating a digital watermarkin the documents to ensure the documents have not been edited afterrelease by the second health institution before identifying them aspatient-collected data.
 13. The method of claim 12, further includingcommunicating electronically directly with the second health institutionto obtain patient-collected data.
 14. The method of claim 1, furtherincluding providing a display output of the physician-generated data forthe given patient to the given patient.
 15. The method of claim 1,further including: (h) accepting into the medical record repositorydatabase patient-collected medical data from the first clinical recordsystem in a manner to be separately identified from thepatient-generated data; and (i) responding to authorization by the givenpatient to transmit at least some of the patient-generated data andpatient-collected data to a second clinical record system.
 16. Themethod of claim 1, further including: (h) responding to authorization bythe given patient to transmit at least some of the patient-generateddata to a second clinical record system.
 17. A health record system,comprising: a medical record repository including at least one computercommunicating with a set of data terminals and a repository database andexecuting a repository program to collect, organize, and display medicaldata controlled by given patients, the medical record repositoryincluding an authentication protocol limiting access by others than thegiven patients, the repository program operating to: (a) storepatient-generated medical data from a patient in a medical recordrepository database on a first computer system; (b) storepatient-collected medical data relating to the patient from a clinicalrecord system in the medical record repository database: (c) storephysician-generated medical data relating to the patient from at leastone clinical record system in the medical record repository database;(d) store an indicator in the medical record repository databaseidentifying stored medical data as patient-generated, patient-collectedor physician-generated, wherein physician-generated medical data isidentified as medical data that has not been collected or generated by apatient; (e) display at least one of the patient-generated,patient-collected, and physician-generated medical data for the patient;wherein the at least one of the patient-generated, patient-collected,and physician-generated medical data is visually linked to a visualindication of an authority of the data based on its identification asphysician-generated having a high level of authority, patient-collectedhaving a medium level of authority, and patient-generated having a lowlevel of authority; and (f) display a numerical ranking indicating thelevel of authority associated with the medical data.
 18. The system ofclaim 17, wherein the operating program further stores an indication ofthe importance of at least one physician-generated medical data asassigned by a health care professional.
 19. The system of claim 17,wherein the operating program further receives authority filterparameters from the physician to suppress the display of medical databased on its identification as physician-generated, patient-generated,or patient-collected.
 20. The system of claim 17, wherein the operatingprogram further receives authority filter parameters from the physicianto suppress the display of selected visual indications of authority.